Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/common/ExternalAPIUtil.java`:
- Around line 452-459: The buildConsentResource method currently autounboxes
nullable fields from ExternalAPIBasicConsentResourceResponseDTO (e.g.,
getFrequency(), getValidityTime(), getRecurringIndicator(), getStatus(), and
potentially getReceipt()), which can cause NPEs for partially populated external
responses; before constructing ConsentResource validate that these boxed values
are non-null (or apply safe defaults) and throw a clear IllegalArgumentException
or return a controlled validation error if any required fields are missing, and
also handle a null receipt from getReceipt() (e.g., treat as empty JSON or
validated error) so ConsentResource(...) is only called with fully validated,
non-null primitive arguments.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/common/model/ExternalAPIBasicConsentResourceRequestDTO.java`:
- Around line 55-57: The JSON parsing of consentResource.getReceipt() in
ExternalAPIBasicConsentResourceRequestDTO is unguarded and can throw
JSONException, aborting updates; wrap the JSONObject construction and toMap()
call in a try-catch that catches org.json.JSONException (or Exception), log or
warn about the malformed receipt (including consent id/context) and gracefully
handle it by leaving this.receipt null or an empty map so the flow continues;
apply the same defensive try-catch and handling to the analogous parsing in
ExternalAPIConsentResourceRequestDTO (the block around lines 63–68).

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/manage/impl/DefaultConsentManageHandler.java`:
- Around line 523-529: The branch that checks
storedConsentResource.getClientID() vs consentManageData.getClientId() leaks
existence by logging NO_CONSENT_FOR_CLIENT_ERROR but throwing
CLIENT_ID_MISMATCH_ERROR; change the thrown ConsentException to use the generic
NO_CONSENT_FOR_CLIENT_ERROR (use
ConsentManageConstants.NO_CONSENT_FOR_CLIENT_ERROR) so both the log and the
thrown error are identical and non-revealing (adjust the ConsentException
constructor call that currently uses
ConsentManageConstants.CLIENT_ID_MISMATCH_ERROR, keeping
ResponseStatus.BAD_REQUEST and ConsentOperationEnum.CONSENT_UPDATE).
- Around line 517-520: The PUT/update error paths in DefaultConsentManageHandler
are mislabeling update failures as delete/create operations; locate where
storedConsentResource is checked and ConsentException is thrown (uses
ConsentException(ResponseStatus.BAD_REQUEST, "Consent not found",
ConsentOperationEnum.CONSENT_DELETE)) and change the operation enum to
ConsentOperationEnum.CONSENT_UPDATE, and similarly update other
throw/catch/helper usages in the same class that currently use CONSENT_CREATE or
CONSENT_DELETE for PUT handling (including the blocks around the
storedConsentResource checks and the exception wrapping logic) so they
consistently use CONSENT_UPDATE and update the error messages from “creating the
consent” to “updating the consent.”
- Around line 552-559: The new ConsentResource instance "updatingConsent" is
missing the stored consent ID so ConsentCoreServiceImpl.updateConsent rejects
it; before calling consentCoreService.updateConsent(updatingConsent) set the
consent ID from storedConsentResource (e.g., call
updatingConsent.setConsentId(storedConsentResource.getConsentId()) or
equivalent) so the update includes the original consent identifier; ensure this
is done in the non-pre-extension branch in DefaultConsentManageHandler where
updatingConsent is constructed from consentManageData and storedConsentResource.
- Around line 470-499: The PUT handling path in DefaultConsentManageHandler is
missing the header validation step (validateRequestHeaders), allowing invalid
requests to proceed; add a call to the same validateRequestHeaders(...) used by
POST/DELETE before any processing (i.e., before checking clientId and
requestPath and before extracting consentId), and ensure it uses the same
operation context (ConsentOperationEnum.CONSENT_UPDATE) and consentManageData
object so invalid headers are rejected early.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/manage/utils/ConsentManageUtils.java`:
- Around line 308-313: The isInternalConsentRequest method currently checks
headers.containsKey with ConsentManageConstants.INTERNAL_API_REQUEST_HEADER
which is case-sensitive; change it to perform a case-insensitive lookup by
iterating the headers map (from consentManageData.getHeaders()) and matching
keys with ConsentManageConstants.INTERNAL_API_REQUEST_HEADER using
equalsIgnoreCase, then parse and return Boolean.parseBoolean of the matched
value (handle nulls by returning false); update only isInternalConsentRequest to
use this key comparison so any header case (e.g., "X-WSO2-Internal-Request") is
recognized.
- Around line 476-480: In ConsentManageUtils update the assignment for the
authorization type so it uses the authorization type field instead of the
status: replace the call to updatedAuthResource.getAuthorizationStatus() passed
to authorization.setType(...) with the appropriate getter for the authorisation
type (e.g., updatedAuthResource.getAuthorizationType()), ensuring the variable
names authorization and updatedAuthResource remain unchanged.
- Around line 427-430: The code currently collects all mapping IDs from
storedResource.getConsentMappingResources() and deactivates them, which disables
mappings for sibling authorisations; update the logic to only collect mapping
IDs whose mapping resource is tied to the current authorization (compare the
mapping resource's authorization id to the authId in scope) before calling
consentCoreService.deactivateAccountMappings; specifically, filter
storedResource.getConsentMappingResources() by mappingResource.getAuthId() (or
equivalent getter) == authId and only add mappingResource.getMappingID() for
those matches.
- Around line 390-391: The catch block in ConsentManageUtils currently catches
ConsentManagementException and always rethrows a ConsentException with
ResponseStatus.BAD_REQUEST (see the catch handling that throws new
ConsentException(ResponseStatus.BAD_REQUEST, e.getMessage(),
ConsentOperationEnum.CONSENT_UPDATE)); change this so only request-validation
errors are mapped to BAD_REQUEST and service/DAO/backend failures are preserved
or translated to server errors: detect whether the caught
ConsentManagementException represents a client validation failure (by checking
its error code/message or a specific type/flag) and if so throw ConsentException
with ResponseStatus.BAD_REQUEST, otherwise either rethrow the original
ConsentManagementException or throw a ConsentException with
ResponseStatus.INTERNAL_SERVER_ERROR (or appropriate server status) so backend
failures are not collapsed into 400s.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/manage/utils/ExternalAPIConsentManageUtils.java`:
- Around line 197-204: The
callExternalService(ExternalAPIPostConsentUpdateRequestDTO) method incorrectly
constructs the request payload via new JSONObject(requestDTO), bypassing
ExternalAPIPostConsentUpdateRequestDTO's custom serialization; update the method
to use requestDTO.toJson() when building requestJson so the nested
consentResource is constructed as intended (keep using
ServiceExtensionTypeEnum.ENRICH_CONSENT_UPDATE_RESPONSE and gson.fromJson on the
response as before).

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/test/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/manage/DefaultConsentManageHandlerTest.java`:
- Around line 166-270: These negative tests currently only assert inside the
catch for ConsentException, so if defaultConsentManageHandler.handlePost(...)
stops throwing the test will pass silently; update each test (e.g.,
testHandlePostWithoutClientId, testHandlePostWithInvalidHeaders,
testHandlePostWithoutRequestPath, testHandlePostWithInvalidRequestPath,
testHandlePostWithInvalidPayload, testHandlePostWithInvalidInitiation) to
explicitly fail when no ConsentException is thrown by calling Assert.fail (or
equivalent) immediately after invoking
defaultConsentManageHandler.handlePost(consentManageDataMock), keeping the
existing catch block assertions for e.getPayload() intact so the test fails when
no exception occurs and still validates the error when one is thrown.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.service/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/service/impl/ConsentCoreServiceImpl.java`:
- Around line 296-313: Replace the prior use of getConsent() (which opens a
separate transaction) with loading the existing row via the DAO on the current
connection before the update (e.g., call
consentCoreDAO.getConsentResourceById(connection,
consentResource.getConsentID()) or the DAO method that returns the persisted
ConsentResource on that connection), fail cleanly if it returns null, then call
consentCoreDAO.updateConsentResource(connection, consentResource), and for the
audit use the persisted snapshot values (the persisted clientId and previous
status) in the consentDataMap and postStateChange call instead of
consentResource.getClientID() and previousConsent.getCurrentStatus(); finally
reload the updated consent from the same DAO/connection after commit (or before
returning) and return that reloaded updated consent.

---

Nitpick comments:
In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/common/ConsentExtensionUtils.java`:
- Around line 123-143: The getInitiationResponse(Object responseObj,
ConsentResource createdConsent) implementation duplicates the same JSON mutation
performed by the DetailedConsentResource overload; extract the shared logic into
a private helper (e.g., populateInitiationData or buildInitiationData) that
accepts the JSONObject response (or its dataObject) and the ConsentResource,
moves the put(...) calls for CONSENT_ID, CREATION_DATE_TIME,
STATUS_UPDATE_DATE_TIME and STATUS, and the remove/put of DATA into that helper,
then replace the body of getInitiationResponse and the DetailedConsentResource
variant to call the helper so both reuse the single implementation.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/test/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/util/DataProviders.java`:
- Around line 48-106: The four unused payload constants in DataProviders
(INITIATION_WITHOUT_PERMISSIONS, INITIATION_WITH_NON_STRING_PERMISSION,
INITIATION_WITHOUT_TRANS_FROM_DATES, INITIATION_WITHOUT_TRANS_TO_DATES) should
be either removed or exercised by tests; update the DataProviders class
accordingly by deleting the unused constants if they’re obsolete, or add unit
tests that reference these constants (e.g., in the consent validation test
suite) to cover missing-permissions, non-string-permission, missing
TransactionFromDateTime, and missing TransactionToDateTime scenarios so the
constants are actually used.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml`:
- Line 11: The embedded OpenAPI document still lists version: v1.0.3 while the
file name indicates v1.0.4—update the OpenAPI info.version field by changing the
version key (the top-level "version:"/info.version entry in
accelerator-extensions-v1.0.4.yaml) to v1.0.4 so docs and generated clients
reflect the correct contract version.
- Around line 2673-2692: The schema FailedResponseApplicationProcess currently
lists a required "data" property that is not defined and defines errorMessage
via a separate object schema (FailedResponseApplicationProcessData) while
examples show a top-level string; remove the nonexistent "data" requirement from
FailedResponseApplicationProcess, change its errorMessage property to type:
string (or inline a string description) instead of $ref to
FailedResponseApplicationProcessData, and delete or simplify the
FailedResponseApplicationProcessData schema (or update references) so the
contract validates failure payloads where "status" is "ERROR" and "errorMessage"
is a plain string.
- Around line 1417-1429: The schema RequestForPreProcessConsentUpdate currently
defines the property storedConsentResource but the DTO
ExternalAPIPreConsentUpdateRequestDTO uses consentResource; rename the YAML
property storedConsentResource to consentResource (and update any $ref usages if
present) so the OpenAPI schema field matches the DTO name and enables correct
deserialization into ExternalAPIPreConsentUpdateRequestDTO.consentResource.
- Around line 2109-2111: Stored consent schemas StoredBasicConsentResourceData
and StoredDetailedConsentResourceData currently define the validityTime property
as type: integer with format: int32; update both definitions so validityTime
uses format: int64 to match ExternalAPIBasicConsentResourceResponseDTO (Long)
and the non-stored consent schemas, preventing downcasting in generated
clients—locate the validityTime field in StoredBasicConsentResourceData and
StoredDetailedConsentResourceData and change format from int32 to int64.
- Around line 2464-2469: The OpenAPI schema for basicConsentData is missing the
array type for additionalProperties: update the basicConsentData object so its
additionalProperties explicitly declares type: array and retains the existing
items: { type: string } so each map value is defined as an array of strings;
locate the basicConsentData definition and add type: array under
additionalProperties (keeping items: type: string) to ensure tools generate
Map<String, List<String>> correctly.
- Around line 836-840: The request body for the operation referencing
PopulateConsentAuthorizeScreenRequestBody is currently treated as optional; set
requestBody.required: true for that operation so generated clients must supply
the payload. Locate the operation that uses the schema reference
'#/components/schemas/PopulateConsentAuthorizeScreenRequestBody' and add a
top-level requestBody.required: true alongside the existing content block
(ensuring the schema name PopulateConsentAuthorizeScreenRequestBody remains
unchanged).

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.dao/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/dao/queries/ConsentMgtCommonDBQueries.java`:
- Around line 44-45: The LEFT JOIN change can produce rows with
ATT_KEY/ATT_VALUE = NULL and the mapper
ConsentManagementDAOUtil.setDataToConsentResourceWithAttributes currently
unconditionally does put(getString(ATT_KEY), getString(ATT_VALUE)), producing
{null=null}; update the mapper to guard against null/blank keys (and optionally
null values) by skipping any ResultSet row where ATT_KEY is null/blank before
calling put, so ConsentCoreDAOImpl.getConsentResourceWithAttributes can safely
use the LEFT JOIN SQL in ConsentMgtCommonDBQueries without creating malformed
attribute entries.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/manage/utils/ConsentManageUtils.java`:
- Around line 361-378: The sequence of non-atomic calls
(consentCoreService.updateAuthorizationResources,
consentCoreService.updateAuthorizationUser, deactivateAccountMappings,
createConsentMappings, then constructUpdateResponse) can leave data inconsistent
if an intermediate call fails; refactor by moving this whole sequence into a
single transactional service method on ConsentCoreService (e.g., add
updateAuthorizationWithMappings(authId, updatingAuthResource, mappingResources)
or similar) that performs updateAuthorizationResources and
updateAuthorizationUser, deactivates and creates mappings inside one DB
transaction and either commits or rolls back, or implement compensating rollback
logic inside that service method to undo prior changes on failure; update the
call site to invoke the new transactional method and return its result (use
AuthorizationResource and List<ConsentMappingResource> handling inside the new
service method).
- Around line 407-416: The extractAuthIdFromPath method can return extra path
segments (e.g., "{authId}/something"); update extractAuthIdFromPath to, after
splitting requestPath by "/authorisations/" and assigning pathParts[1], further
split that segment by "/" and take the first element as the authId (trim it),
then validate it as before; ensure you still log the same error message via
log.error and throw ConsentManagementException when authId is blank or missing.
Use the existing method name extractAuthIdFromPath and the local variable authId
to locate and apply this change.

---

Duplicate comments:
In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/manage/impl/DefaultConsentManageHandler.java`:
- Around line 592-595: The catch block for ConsentManagementException in
DefaultConsentManageHandler currently logs "Error Occurred while creating the
consent" which is inconsistent with the update flow; change the log.error
message in that catch (ConsentManagementException e) block to "Error Occurred
while updating the consent" (matching the ConsentException message) so the log
and thrown ConsentException both refer to the update operation.

---

Nitpick comments:
In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/common/ConsentExtensionUtils.java`:
- Around line 123-149: The two getInitiationResponse methods duplicate logic;
extract the common JSON construction into a private helper (e.g.,
buildInitiationResponse) that takes (Object responseObj, String consentId, long
createdTime, long updatedTime, String status) and performs the JSONObject
dataObject population and replacement, then have both public methods call this
helper (getInitiationResponse(Object, DetailedConsentResource) and
getInitiationResponse(Object, ConsentResource) pass their respective
createdConsent fields into buildInitiationResponse); keep the existing debug log
only in the ConsentResource overload after calling the helper.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/manage/impl/DefaultConsentManageHandler.java`:
- Around line 508-516: The request path check using
consentManageData.getRequestPath().contains("authorisations") is too permissive;
update the conditional in DefaultConsentManageHandler so it matches the intended
route pattern (e.g., segment-based or regex like .*/authorisations/.*) instead
of a substring match; locate the block that calls
ConsentManageUtils.isInternalConsentRequest(...) and replace the contains(...)
check with a precise match (regex or parsed path segment comparison) so only
requests matching the pattern /authorisations/ (as a path segment) trigger
ConsentManageUtils.updateConsentAuthResource and the subsequent response
handling.

In
`@financial-services-accelerator/components/org.wso2.financial.services.accelerator.consent.mgt.extensions/src/main/java/org/wso2/financial/services/accelerator/consent/mgt/extensions/manage/model/ConsentManageAuthorizationUpdateDTO.java`:
- Around line 28-34: The field mappingResources in
ConsentManageAuthorizationUpdateDTO currently has package-private access while
all other fields are private; change its declaration to private
List<MappingResource> mappingResources to match encapsulation, and ensure any
existing getter/setter methods (e.g., getMappingResources/setMappingResources)
reference the renamed private field if needed.